🚀 Package Preview Available!

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.0.44-pr.395.5afac9a

Prefer not to change any import paths? Install using npm alias so your code still imports base44:

npm i "base44@npm:@base44-preview/cli@0.0.44-pr.395.5afac9a"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.0.44-pr.395.5afac9a"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.0.44-pr.395.5afac9a
• 🔗 View this commit on GitHub

_{Preview published to npm registry — try new features instantly!}

@claude review

Claude finished @artemdemo's task in 1m 56s —— View job

PR Review: Schemas Validation

• Gather context and understand PR
• Read changed files
• Analyze code quality, correctness, and patterns
• Post review feedback

Overall this is a clean, well-structured addition. The Validator class is focused, recursive validation works correctly for nested arrays/objects, and the test coverage is thorough. A few issues worth addressing:

Issues

1. null values fail type validation silently-but-wrongly

validateValue does not handle null explicitly. If a client sends { "name": null } to clear an optional string field, the validator rejects it with "Input should be a valid string" — because typeof null === "object", not "string". For the object case the null guard returns an error too (line 162). This is likely unintentional; nulls are common for clearing optional fields.

File: packages/cli/src/cli/dev/dev-server/db/validator.ts:116

Suggestion: return early with { hasError: false } before the switch if value === null (or align with production API behaviour for null).

Fix this →

2. Misleading error for unsupported schema types

When a property's type field contains an unsupported value (e.g. "date"), the error returned is "Input should be a valid date" — this reads as if the user's value is wrong, when actually the schema type itself is unrecognised.

File: packages/cli/src/cli/dev/dev-server/db/validator.ts:129-135

// current
`Error in field ${fieldPath}: Input should be a valid ${propertyType}`

// clearer
`Error in field ${fieldPath}: Unsupported field type "${propertyType}"`

3. Bulk create doesn't identify which record failed validation

POST /:entityName/bulk validates each record in a loop but the error response doesn't include which index failed. A client sending 10 records has no way to know which one caused the 422.

File: packages/cli/src/cli/dev/dev-server/routes/entities.ts:253-260

Consider including the record index in the validation error message, or at minimum in a wrapper field (e.g. { index: i, ...validation.error }).

4. validateRequiredFields treats null as missing

record[required] == null (loose equality) catches both undefined and null. If a client explicitly sends null for a required field on a create, the error will say "Field required" rather than a type error — which may be the right behaviour, but is worth an explicit test.

File: packages/cli/src/cli/dev/dev-server/db/validator.ts:216

Nits

• vitest.config.ts:9 — testTimeout is missing indentation (4 spaces). The PR description says this file change is unrelated lint cleanup, but the formatting was made worse.
• validator.ts:25-32 — The fieldTypes array and the switch statement below are loosely coupled. Adding a new type to fieldTypes (e.g. "null") won't automatically add handling in the switch, making default the fallback. A comment noting this relationship would help.
• database.ts:33 — validate and prepareRecord both throw Error if the schema is missing, but withCollection already guards against unknown entity names, so this code path is unreachable in practice. A comment or a /* istanbul ignore next */ would clarify intent.

What's good

• The filterFields → applyDefaults → validate ordering in prepareRecord/route handlers is correct.
• partial: true for PUT correctly skips required-field checks while still validating types.
• Recursive validation for nested arrays-of-objects works correctly (confirmed by the entries[0].count test).
• ValidationError response shape (error_type, message, request_id, traceback) intentionally mirrors production — good for parity.
• The Database class cleanly encapsulates both the NeDB datastore and the schema store; load/dropAll are symmetric.
• Test coverage is comprehensive; the "temporary" skips are honestly documented.

| Branch: schemas-validation